fix(DX-10060): retry transient network errors to prevent build crashes - #385

Adds default retry behavior for transient network-layer failures in the Delivery SDK by composing a new network-error retry check with any user-provided retryCondition, and documents/releases the change as a minor version bump.

Changes:

• Composes a combinedRetryCondition in the stack client to retry common transient network error codes while preserving the original user retryCondition reference.
• Adds a utility helper (isTransientNetworkError) + constant set of retryable network error codes.
• Introduces unit tests covering the new retry behavior and updates version/changelog to 5.6.0.

• Files reviewed: 5/5 changed files
• Comments generated: 3
• Review effort level: Lite

Suppressed comments (3)

CHANGELOG.md:2

• The Version 5.6.0 changelog entry leaves the Date field blank, but other entries consistently include a formatted date (e.g. "#### Date: Aug-03-2026"). Please fill this in so releases are traceable.

#### Date:

src/common/utils.ts:41

• The @returns description only mentions matching error.code, but the implementation also requires that there is no HTTP response (!error.response). Updating the JSDoc will keep the contract accurate for readers.

 * @returns {boolean} True if `error.code` matches a known transient network error code

src/common/utils.ts:39

• This JSDoc sentence is grammatically inverted: it currently reads as if the caller would not be retried ("instead of being silently retried"), which contradicts the function’s purpose and the PR description. Reword so it clearly states the error is retried rather than failing immediately.

 * Determines whether an error represents a transient, retryable network-layer
 * failure (e.g. DNS lookup failure, connection reset), used to build the SDK's
 * default retry behavior so a single blip doesn't crash the caller (e.g. a
 * Next.js static build) instead of being silently retried.

• Files reviewed: 5/5 changed files
• Comments generated: 0 new
• Review effort level: Lite

Suppressed comments (2)

CHANGELOG.md:4

• The 5.6.0 changelog text reads like transient network errors are being retried for the first time, but 5.5.1 already documents default retry of transient network-level errors. Consider rewording this entry to clarify what specifically changed in 5.6.0 (e.g., composition with user-supplied retryCondition / behavior when retryCondition is present).

Fix: Transient network-layer errors (ENOTFOUND, ENETUNREACH, ECONNRESET, ECONNREFUSED, EAI_AGAIN, ETIMEDOUT, EHOSTUNREACH, ENETDOWN) are now retried automatically using the SDK's configured retry policy instead of failing immediately.
Enhancement: User-supplied `retryCondition` is composed with the default network-error retry logic — both are honoured without either replacing the other. If `retryCondition` throws, the SDK logs a warning via `logHandler` and falls back to default retry behaviour.

src/common/utils.ts:42

• This JSDoc sentence is currently confusing: it implies the caller crashes "instead of being silently retried", but this helper exists to enable retries. Reword to reflect that transient network failures are retried according to policy to avoid crashing callers (e.g., build steps).

 * Determines whether an error represents a transient, retryable network-layer
 * failure (e.g. DNS lookup failure, connection reset), used to build the SDK's
 * default retry behavior so a single blip doesn't crash the caller (e.g. a
 * Next.js static build) instead of being silently retried.
 * @param {any} error - The error thrown by the underlying HTTP client (Axios)
 * @returns {boolean} True if `error.code` matches a known transient network error code and no HTTP response was received (`error.response` is absent)
 */

• Files reviewed: 5/5 changed files
• Comments generated: 0 new
• Review effort level: Lite